This PR will not be compatible with the relm4 port, so will need to be redone and reconsidered.

Custom image support would definitely be nice, but at least the current implementation with the stdin does not really feel good. It would be better if the stdin plugin had an option to parse json as the input instead of just newlines.

What if instead of creating a new "image" field, just use the existing "icon" field?
Check if the value provided to "icon" is a path. If it is, then display the image. If not, it will act as the old "icon" field.

Also, I wonder if support for animated images would be possible.

Currently we are discussing this in the Matrix room, and are thinking of making a separate field that would allow for different previews & preview types for plugins. How they are drawn is still up for debate though.

What if instead of creating a new "image" field, just use the existing "icon" field? Check if the value provided to "icon" is a path. If it is, then display the image. If not, it will act as the old "icon" field.

Also, I wonder if support for animated images would be possible.

This was a while ago, but IIRC, there was a reason I didn't do that.

I wanted to briefly note here that I'm migrating away from rofi+cliphist and would love to use anyrun in combination with a clipboard manager that can provide image previews, so if this MR could be leveraged to support that, it'd be ideal.

The rofi + cliphist implementation is pretty hacky (it generates thumbnails on the fly that it injects with rofi's unique string interpolation syntax) but I was imagining potentially doing something like talking to the sqlite backend for clipvault to retrieve images from within rust to more natively have image bytes to work with and potentially render somewhere.

Of course you could do this with an anyrun daemon in the background listening to wl-copy or whatever but in either case we'd be working with image data bytes.

As it is right now, no plugin can run as a daemon, so unless the clipboard manager was implemented inside Anyrun proper (which doesn't sound great to me since it sidesteps the whole point of plugins being independent) it wouldn't really work out. As for the image support itself, I think a better way would be to design a system that would:

• Allow for multiple different preview types, this could be done by having something like a Preview enum as a part of matches.
  • This would make it extensible, allowing stuff like text file preview as well.
• Allow the preview data to be provided as is or dynamically generated, this would require some sort of a callback into the plugin for generating the preview. So another function as a part of the plugin definition is probably necessary (but should be optional).
  • This would be useful for stuff like the niri-focus plugin, where window previews would only need to be generated on demand.

Of course the UI stuff also needs some thought (where & how the preview should be shown) but that can be rapidly iterated upon after the underlying stuff is done.